Three steps to more server wisdom

Three steps to more server wisdom

The usage of WebStress is very simple and consists of three steps:

Select a URL on your server

Run the server load test and WebStress records request times, number of errors

Run the web browser test and WebStress measures the time a surfer needs to receive the complete webpage

Step 1: Select a URL

Enter any URL into the editfield as you are used to from your browser and click on Go to URL. In the lower part of the window a web browser appears, downloads the webpage and displays it. Using your mouse you can surf through the website. Note that the new URLs appear in the editfield as soon as you click on them.

Hint: Pages that make use of frames do not show the correct URLs in the edit field!

Step 2: Server Load Test

When you have navigated to the webpage that you want to test, click on the tab Load Test The Server.

Here you again find the URL that is to tested, lots of settings and the tb control with the result pages at the bottom.

First select the number of simultaneous users you want to simulate (e.g. 10) and set Number of Runs to the value 1. If you use a proxy-server, if the webpages needs user authentification or some special user agent, please enter the appropiate data. Switch off all other settngs.

Now hit Start Test and watch WebStress stress your server. After the test is done you can view the results in the lower tab control:

Graph: shows one vertical bar for every request. The height shows how long the request took to complete, the position from the left corner shows when the request was started. The footer of the graph shows: Count of requests by statuscode, the type of the test, the average request time for all tests and the theoretical possible number of requests per hour

Results: shows a summary of the most important numbers gathered during the test

Log: every event and data of the test is recorded in this logfile

Browserview: shows the resulting HTML of the first request using a web browser, which is also written to "temp.htm" in the path of webstress3.exe

Source: shows the HTML code resulting from the first request

Rcvd. Headers: shows the HTTP-Headers of the first request

Now you know if your server can handle 10 simultaneous users. But happens if there are more users.

Switch on Ramp Test, set number of users to 100 and number of runs to 10. When you click on Start Test now, WebStress simulates 10, 20, 30 ... 100 users, increasing the number with every run until the maximum number you have entered.

When the test is finshed, switch to the Graph tab and watch the lower graph. The graph shows the results of the ramp test, i.e. the average request time in relation to the number of simultaneous users.

This graph would be perfect, if he line would plot horizontally from left to right wich would mean, hat the average request time has no relation to the number of users. But I haven't found a server like that yet... :-)

All other settings are described below.

Step 3: Web Browser Test

Now you know what your web server can handle for one page, but how long does a browser on the surfers machine need to download and display the complete page.

In the main notebook click on the tab Measure Client's download time and afterwards click on Start Test.

The web browser requests and downloads the complete page two times now, during the second download a clock is running and after successfull download WebStress shows the download time just below the Start Test button.

Tips&Tricks

For all these tests the bandwidth between you and the server is critical. Obviously you will not be able to correctly simulate 100 users via a 33k modem connection to the internet. The most accurate results are possible if you are connected to the same hub as your server.

The longer it takes for the server to calculate one requests the smaller is the influence of bandwidth and network time for WebStress' calculations.

Since WebStress needs some time for internal calculations it is not recommended to run WebStress on the same machine as the tested webserver and it is recommended to switch the Exact Timing on.

To simply measure request times for a page 5 runs with 10 users should be sufficient for correct results

The settings in detail

Number of Users

The number of simultaneous users to be simulated

Number of Runs

The number of runs

Wait per Run

The time in seconds Webstress should wait until starting the next run

Please notice the difference between "runs" and "users". You can simulate 100 users in one run, then wait for 10 seconds, start a new run with 100 users, wait for 10 seconds etc.

Ramp Test

ON: Increases the number of users with each run up to the given number of users. When ON an additional graph shows the results.

Preserver Cookies

ON: The cookies (e.g. ASP session IDs) coming from the server in the first run are sent to the server during the following runs. This simulates a number of users loging in and then using the system.
OFF: Cookies are not handled

Exact Timing/Hide Graph

ON: The graphs, statistics etc. are hidden during the tests => the time measurement is more exact because no time is needed for screen updates
OFF: The graphs are shown during the test, better to see what is happening but timing might not be exact

Write Headers to Log, Write Data to Log

ON: The Headers/Data is written to the webstress log (see log-tab)

Write On Error Only

ON: The Headers/Data is only written to the log when the http-result is not 200, which means an error occured

Use Proxy

ON: WebStress uses the given proxy for the http requests

Use User

ON: WebStress sends the given user data (Username/PW) with the http-requests

Use Agent

ON: WebStress send the given user agent with the http-requests, e.g. to simulate different browers to the server. A list of most used browser strings is included

Key Offset

ON: Replaces a @@ in the URL with an ascending number for every user, the number start with the number given in the edit field

Number of Users	The number of simultaneous users to be simulated
Number of Runs	The number of runs
Wait per Run	The time in seconds Webstress should wait until starting the next run

Ramp Test	ON: Increases the number of users with each run up to the given number of users. When ON an additional graph shows the results.
Preserver Cookies	ON: The cookies (e.g. ASP session IDs) coming from the server in the first run are sent to the server during the following runs. This simulates a number of users loging in and then using the system. OFF: Cookies are not handled
Exact Timing/Hide Graph	ON: The graphs, statistics etc. are hidden during the tests => the time measurement is more exact because no time is needed for screen updates OFF: The graphs are shown during the test, better to see what is happening but timing might not be exact
Write Headers to Log, Write Data to Log	ON: The Headers/Data is written to the webstress log (see log-tab)
Write On Error Only	ON: The Headers/Data is only written to the log when the http-result is not 200, which means an error occured
Use Proxy	ON: WebStress uses the given proxy for the http requests
Use User	ON: WebStress sends the given user data (Username/PW) with the http-requests
Use Agent	ON: WebStress send the given user agent with the http-requests, e.g. to simulate different browers to the server. A list of most used browser strings is included
Key Offset	ON: Replaces a @@ in the URL with an ascending number for every user, the number start with the number given in the edit field